Many devices include one or more image sensors and/or image displays, and an image processing unit may facilitate the processing of data coming from the sensor, being provided to the display, and/or is otherwise being utilized by applications running on the device. For example, a smart phone might include a number of different cameras and a touch screen. The image processing unit may include an image computation fabric having a number of different components to process image information.
In some cases, the image processing unit may execute a series of image primitives to create output image data (e.g., to be sent to a touch screen) based on input image data (e.g., received from a smart phone's camera). The image primitives may be, for example, associated with an image primitive library and might include, for example, sensor primitives, calibration primitives, optics primitives, etc.
Typically, an application executing in connection the image processing unit determines which image primitives will be executed by the various components of the image computation fabric. For example, the application might determine that a filter primitive will be executed by fixed function hardware. Such an approach, however, can have several disadvantages. For example, the application might be unaware that another application is also attempting to use the same fixed function hardware. As a result, an application may “stall” or need to wait until the fixed function hardware becomes free, and the performance of the system may be degraded.
Moreover, the substantial number and relative complexity of image primitives (and the fact that they may operate differently in connection with different components of different image execution fabrics) may result in substantial software development costs and inhibit innovation for application software developers (who may be forced to create customized software for each new platform).